Hi All,

With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
[2], with other various optimizations to compiler and runtime, and with previous
release published sometime back in 2005 [3], now is the best, or at the very
least, really good time to to cut next, 1.5 release of the venerable Jakarta
Regexp package.

Please try out current svn (r517970) version [4] and test for any regressions,
and vote for a release. Regexp test suite can be run by issuing 'ant test' in
the checkout directory, and does not take even 3 seconds to complete.
Interactive testing can be done by using applet version [5].

The only known incompatibility with Regexp 1.4 is that pre-compiled RE programs
created with 'recompile' utility [6] for patterns containing reluctant closures
are not compatible with trunk. But, that should not be a problem since they did
not work correctly before anyway [7].

My vote for the release is +1.

Thanks,
Vadim

[1] http://jakarta.apache.org/regexp/changes.html
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
[3] http://marc.info/?l=jakarta-regexp-dev&m=112429683615736
[4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
[5] http://jakarta.apache.org/regexp/applet.html
[6]
http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/jav a/org/apache/regexp/recompile.java
[7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763

Hm,

I hate to spoil you here but according to a recent board discussion,
some discussion on private [at] velocity and a completely botched release
attempt in Velocity land:

You actually have to roll and sign a tarball/zip ball on which the vote
happens. "Release-then-Vote" seems to be the only accepted way by the
board these days; personally I do prefer "Vote-then-Release" myself but
that seems to be the way it is.

On the release itself I'm +1, on the procedure I prefer to abstain. :-)

Best regards
Henning



On Tue, 2007-03-13 at 22:12 -0400, Vadim Gritsenko wrote:
> Hi All,
>
> With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
> [2], with other various optimizations to compiler and runtime, and with previous
> release published sometime back in 2005 [3], now is the best, or at the very
> least, really good time to to cut next, 1.5 release of the venerable Jakarta
> Regexp package.
>
> Please try out current svn (r517970) version [4] and test for any regressions,
> and vote for a release. Regexp test suite can be run by issuing 'ant test' in
> the checkout directory, and does not take even 3 seconds to complete.
> Interactive testing can be done by using applet version [5].
>
> The only known incompatibility with Regexp 1.4 is that pre-compiled RE programs
> created with 'recompile' utility [6] for patterns containing reluctant closures
> are not compatible with trunk. But, that should not be a problem since they did
> not work correctly before anyway [7].
>
> My vote for the release is +1.
>
> Thanks,
> Vadim
>
> [1] http://jakarta.apache.org/regexp/changes.html
> [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
> [3] http://marc.info/?l=jakarta-regexp-dev&m=112429683615736
> [4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
> [5] http://jakarta.apache.org/regexp/applet.html
> [6]
> http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/jav a/org/apache/regexp/recompile.java
> [7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
--
Henning P. Schmiedehausen -- hps [at] intermeta.de | J2EE, Linux, |gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design | Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n

Henning Schmiedehausen wrote:
> Hm,
>
> I hate to spoil you here but according to a recent board discussion,
> some discussion on private [at] velocity and a completely botched release
> attempt in Velocity

My condolences to you...


> land:
>
> You actually have to roll and sign a tarball/zip ball on which the vote
> happens. "Release-then-Vote" seems to be the only accepted way by the
> board these days;

Thankfully, neither events in velocity-private nor board feelings apply here.
Either Jakarta PMC votes for it or receives an resolution, before that happens,
existing procedures [1] stay.


> personally I do prefer "Vote-then-Release" myself but
> that seems to be the way it is.

Agree. Doing otherwise is putting carriage before the horse. The closest I can
do to satisfy old ladies drinking tea is this "rc" trunk build [2]. Of course
those are not the files to be distributed: to get those, I actually would have
to do release first. And that would put me in catch 22 situation. Hence these RC
builds have to suffice.


> On the release itself I'm +1, on the procedure I prefer to abstain. :-)

Thanks! Now need one more before starting tagging. Also I think I need to update
headers as per [3], is that correct?

Vadim

[1] http://jakarta.apache.org/commons/releases/release.html
[2] http://people.apache.org/~vgritsenko/regexp/
[3] http://www.apache.org/legal/src-headers.html


> Best regards
> Henning
>
>
>
> On Tue, 2007-03-13 at 22:12 -0400, Vadim Gritsenko wrote:
>> Hi All,
>>
>> With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
>> [2], with other various optimizations to compiler and runtime, and with previous
>> release published sometime back in 2005 [3], now is the best, or at the very
>> least, really good time to to cut next, 1.5 release of the venerable Jakarta
>> Regexp package.
>>
>> Please try out current svn (r517970) version [4] and test for any regressions,
>> and vote for a release. Regexp test suite can be run by issuing 'ant test' in
>> the checkout directory, and does not take even 3 seconds to complete.
>> Interactive testing can be done by using applet version [5].
>>
>> The only known incompatibility with Regexp 1.4 is that pre-compiled RE programs
>> created with 'recompile' utility [6] for patterns containing reluctant closures
>> are not compatible with trunk. But, that should not be a problem since they did
>> not work correctly before anyway [7].
>>
>> My vote for the release is +1.
>>
>> Thanks,
>> Vadim
>>
>> [1] http://jakarta.apache.org/regexp/changes.html
>> [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
>> [3] http://marc.info/?l=jakarta-regexp-dev&m=112429683615736
>> [4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
>> [5] http://jakarta.apache.org/regexp/applet.html
>> [6]
>> http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/jav a/org/apache/regexp/recompile.java
>> [7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763

On 14/03/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
> Henning Schmiedehausen wrote:
> > Hm,
> >
> > I hate to spoil you here but according to a recent board discussion,
> > some discussion on private [at] velocity and a completely botched release
> > attempt in Velocity
>
> My condolences to you...
>
>
> > land:
> >
> > You actually have to roll and sign a tarball/zip ball on which the vote
> > happens. "Release-then-Vote" seems to be the only accepted way by the
> > board these days;
>
> Thankfully, neither events in velocity-private nor board feelings apply here.
> Either Jakarta PMC votes for it or receives an resolution, before that happens,
> existing procedures [1] stay.
>
>
> > personally I do prefer "Vote-then-Release" myself but
> > that seems to be the way it is.
>
> Agree. Doing otherwise is putting carriage before the horse. The closest I can
> do to satisfy old ladies drinking tea is this "rc" trunk build [2]. Of course
> those are not the files to be distributed: to get those, I actually would have
> to do release first. And that would put me in catch 22 situation. Hence these RC
> builds have to suffice.
>
>
> > On the release itself I'm +1, on the procedure I prefer to abstain. :-)
>
> Thanks! Now need one more before starting tagging. Also I think I need to update
> headers as per [3], is that correct?

You also need a NOTICE file [3]

The LICENSE and NOTICE files ought to go into the jar as well, as the
jar may well be used on its own.

License should be LICENSE [3]

> Vadim
>
> [1] http://jakarta.apache.org/commons/releases/release.html
> [2] http://people.apache.org/~vgritsenko/regexp/

It would be nice if the MD5 files used the more standard format:

9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip

so that MD5 tools can process the file automatically.


> [3] http://www.apache.org/legal/src-headers.html
>
>
> > Best regards
> > Henning
> >
> >
> >
> > On Tue, 2007-03-13 at 22:12 -0400, Vadim Gritsenko wrote:
> >> Hi All,
> >>
> >> With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
> >> [2], with other various optimizations to compiler and runtime, and with previous
> >> release published sometime back in 2005 [3], now is the best, or at the very
> >> least, really good time to to cut next, 1.5 release of the venerable Jakarta
> >> Regexp package.
> >>
> >> Please try out current svn (r517970) version [4] and test for any regressions,
> >> and vote for a release. Regexp test suite can be run by issuing 'ant test' in
> >> the checkout directory, and does not take even 3 seconds to complete.
> >> Interactive testing can be done by using applet version [5].
> >>
> >> The only known incompatibility with Regexp 1.4 is that pre-compiled RE programs
> >> created with 'recompile' utility [6] for patterns containing reluctant closures
> >> are not compatible with trunk. But, that should not be a problem since they did
> >> not work correctly before anyway [7].
> >>
> >> My vote for the release is +1.
> >>
> >> Thanks,
> >> Vadim
> >>
> >> [1] http://jakarta.apache.org/regexp/changes.html
> >> [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
> >> [3] http://marc.info/?l=jakarta-regexp-dev&m=112429683615736
> >> [4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
> >> [5] http://jakarta.apache.org/regexp/applet.html
> >> [6]
> >> http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/jav a/org/apache/regexp/recompile.java
> >> [7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

sebb wrote:
>> Also I think I need to update
>> headers as per [3], is that correct?
>
> You also need a NOTICE file [3]

Updated license headers, added NOTICE to zip/tar.gz.


> The LICENSE and NOTICE files ought to go into the jar as well, as the
> jar may well be used on its own.

Added both files to the META-INF directory of the jar file.


> License should be LICENSE [3]

Yep, it is there [1]. Exact copy.


>> [2] http://people.apache.org/~vgritsenko/regexp/
>
> It would be nice if the MD5 files used the more standard format:
>
> 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
>
> so that MD5 tools can process the file automatically.

Which tools you have in mind? All tools known and available to me (locally and
on p.a.o) produce the output

MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8

The only exception is 'md5 -r', but it does not put '*' before file name.


Thanks for all the feedback. Files, now using r518169, are re-built and
re-uploaded [2].

Vadim

[1] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/LICENSE
[2] http://people.apache.org/~vgritsenko/regexp/

On 14/03/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
> sebb wrote:
> >> Also I think I need to update
> >> headers as per [3], is that correct?
> >
> > You also need a NOTICE file [3]
>
> Updated license headers, added NOTICE to zip/tar.gz.
>
>
> > The LICENSE and NOTICE files ought to go into the jar as well, as the
> > jar may well be used on its own.
>
> Added both files to the META-INF directory of the jar file.
>
>
> > License should be LICENSE [3]
>
> Yep, it is there [1]. Exact copy.
>

The LICENSE and NOTICE files are now in the zip and jar, but they show
up for me as License and Notice. Ideally they should be in capitals.

>
> >> [2] http://people.apache.org/~vgritsenko/regexp/
> >
> > It would be nice if the MD5 files used the more standard format:
> >
> > 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
> >
> > so that MD5 tools can process the file automatically.
>
> Which tools you have in mind? All tools known and available to me (locally and
> on p.a.o) produce the output
>
> MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8
>
> The only exception is 'md5 -r', but it does not put '*' before file name.

The '*' is supposed to be used for binary files; otherwise use ' ' (space).

The ones I have seen are:

http://en.wikipedia.org/wiki/Md5sum
http://mirror.href.com/thestarman/DOS/MD5progs.html#format
http://www.fourmilab.ch/md5/

Also the Tomcat MD5s (for example).



>
> Thanks for all the feedback. Files, now using r518169, are re-built and
> re-uploaded [2].
>
> Vadim
>
> [1] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/LICENSE
> [2] http://people.apache.org/~vgritsenko/regexp/
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

+1

sebb wrote:
> The LICENSE and NOTICE files are now in the zip and jar, but they show
> up for me as License and Notice. Ideally they should be in capitals.

They are:

vgritsenko [at] minotaur ~/public_html/regexp $ tar -tzf
jakarta-regexp-1.5-dev.tar.gz | grep "dev/[^dsx]"
jakarta-regexp-1.5-dev/LICENSE
jakarta-regexp-1.5-dev/NOTICE
jakarta-regexp-1.5-dev/README

vgritsenko [at] minotaur ~/public_html/regexp $ unzip -l jakarta-regexp-1.5-dev.zip |
grep "dev/[^dsx]"
11357 03-14-07 10:05 jakarta-regexp-1.5-dev/LICENSE
302 03-14-07 10:05 jakarta-regexp-1.5-dev/NOTICE
901 03-14-07 10:05 jakarta-regexp-1.5-dev/README

vgritsenko [at] minotaur ~/public_html/regexp $ unzip jakarta-regexp-1.5-dev.zip
jakarta-regexp-1.5-dev/jakarta-regexp-1.5-dev.jar

vgritsenko [at] minotaur ~/public_html/regexp $ unzip -l
jakarta-regexp-1.5-dev/jakarta-regexp-1.5-dev.jar | grep -v org
Archive: jakarta-regexp-1.5-dev/jakarta-regexp-1.5-dev.jar
Length Date Time Name
-------- ---- ---- ----
0 03-14-07 10:04 META-INF/
106 03-14-07 10:04 META-INF/MANIFEST.MF
11357 03-14-07 09:52 META-INF/LICENSE
302 10-31-06 22:36 META-INF/NOTICE
-------- -------
62348 24 files



>> >> [2] http://people.apache.org/~vgritsenko/regexp/
>> >
>> > It would be nice if the MD5 files used the more standard format:
>> >
>> > 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
>> >
>> > so that MD5 tools can process the file automatically.
>>
>> Which tools you have in mind? All tools known and available to me
>> (locally and on p.a.o) produce the output
>>
>> MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8
>>
>> The only exception is 'md5 -r', but it does not put '*' before file name.
>
> The '*' is supposed to be used for binary files; otherwise use ' ' (space).
>
> The ones I have seen are:
>
> http://en.wikipedia.org/wiki/Md5sum

It's not found on apache boxes.

> http://mirror.href.com/thestarman/DOS/MD5progs.html#format
> http://www.fourmilab.ch/md5/

That's exactly what I used. As mentioned above, can use 'md5 -r' if you prefer
it more. I guess that's exactly what you had in mind.

Vadim

On 14/03/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
> sebb wrote:
> > The LICENSE and NOTICE files are now in the zip and jar, but they show
> > up for me as License and Notice. Ideally they should be in capitals.
>
> They are:
>
> vgritsenko [at] minotaur ~/public_html/regexp $ tar -tzf
> jakarta-regexp-1.5-dev.tar.gz | grep "dev/[^dsx]"
> jakarta-regexp-1.5-dev/LICENSE
> jakarta-regexp-1.5-dev/NOTICE
> jakarta-regexp-1.5-dev/README

Sorry, just discovered that Winzip was being "helpful" and converting
the file name...

> >> >> [2] http://people.apache.org/~vgritsenko/regexp/
> >> >
> >> > It would be nice if the MD5 files used the more standard format:
> >> >
> >> > 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
> >> >
> >> > so that MD5 tools can process the file automatically.
> >>
> >> Which tools you have in mind? All tools known and available to me
> >> (locally and on p.a.o) produce the output
> >>
> >> MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8
> >>
> >> The only exception is 'md5 -r', but it does not put '*' before file name.
> >
> > The '*' is supposed to be used for binary files; otherwise use ' ' (space).
> >
> > The ones I have seen are:
> >
> > http://en.wikipedia.org/wiki/Md5sum
>
> It's not found on apache boxes.

Some / most users are not on apache boxes...

> > http://mirror.href.com/thestarman/DOS/MD5progs.html#format
> > http://www.fourmilab.ch/md5/
>
> That's exactly what I used. As mentioned above, can use 'md5 -r' if you prefer
> it more. I guess that's exactly what you had in mind.
>

Well, either format will do for humans.

The format I am suggesting is supported as input to some programs that
can be used to check the MD5s - is the other format usable as input?
If so, which program(s)?

But anyway:

+1 to the release

S///

On 3/14/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
> Henning Schmiedehausen wrote:

> > You actually have to roll and sign a tarball/zip ball on which the vote
> > happens. "Release-then-Vote" seems to be the only accepted way by the
> > board these days;
>
> Thankfully, neither events in velocity-private nor board feelings apply here.
> Either Jakarta PMC votes for it or receives an resolution, before that happens,
> existing procedures [1] stay.

There are (to my knowledge) three types of vote/release styles that
have been happening at the ASF.

1) A vote to do a release, with no sign of release files. This is how
this thread started and it's against ASF policy.

2) A vote on release-candidate files (or -dev in your case), and then
a release that is trusted to be a repeat of the process used. This is
currently a grey area policy-wise, and is where this release moved to
with the ~/vgritsenko/*-dev files.

3) Creating the actual files that are going to be released and voting
on them. There's pressure to go this way, but it's not the policy yet.

> > personally I do prefer "Vote-then-Release" myself but
> > that seems to be the way it is.

Release-then-Vote has some nice parts, the actual release is really
easy. That's nice if the release process has been painful as it means
I don't have to remember how to do the damn thing. Vote-then-Release
is nice in that you don't end up doing as many vote builds.

Other parts of the ASF seem to do a release where they make a build
and if it passes a vote it goes out, if it doesn't then they up the
bugfix number and do it again (I don't think anyone actually has a
build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that
the version number doesn't show. Very confusing as a user I think.

Mostly at this stage the mandate is that we have to be voting on
release files, not on "Hey, how about a release".

Hen

The vote to release passes with +1s from:

Vadim Gritsenko
Henning Schmiedehausen
Daniel F. Savarese
sebb


Henri Yandell wrote:
> There are (to my knowledge) three types of vote/release styles that
> have been happening at the ASF.
>
> 1) A vote to do a release, with no sign of release files. This is how
> this thread started and it's against ASF policy.

Can you put a finger on this policy? I'm not sure I'm aware of such policy.

> 2) A vote on release-candidate files (or -dev in your case), and then
> a release that is trusted to be a repeat of the process used. This is
> currently a grey area policy-wise, and is where this release moved to
> with the ~/vgritsenko/*-dev files.

Indeed.

> 3) Creating the actual files that are going to be released and voting
> on them. There's pressure to go this way, but it's not the policy yet.
>
>> > personally I do prefer "Vote-then-Release" myself but
>> > that seems to be the way it is.
>
> Release-then-Vote has some nice parts, the actual release is really
> easy. That's nice if the release process has been painful as it means
> I don't have to remember how to do the damn thing. Vote-then-Release
> is nice in that you don't end up doing as many vote builds.
>
> Other parts of the ASF seem to do a release where they make a build
> and if it passes a vote it goes out, if it doesn't then they up the
> bugfix number and do it again (I don't think anyone actually has a
> build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that
> the version number doesn't show. Very confusing as a user I think.

Agree.

> Mostly at this stage the mandate is that we have to be voting on
> release files, not on "Hey, how about a release".

This is the single most valuable vote. Either community has a consensus on
status of code in question - is it ready to be a GA release? - or not. There is
some limited sense on voting on final files - just to make sure RM did not
messed up in the process - but it has no much value over "Hey, how about a
release" vote, and adds to the confusion, as you correctly noted above.

Vadim

Henri Yandell wrote:

<snip/>

PS I noticed that you forgot to vote this year :-)
http://marc.info/?l=jakarta-general&m=112388881425543

Vadim

Henri Yandell wrote:
> 3) Creating the actual files that are going to be released and voting
> on them. There's pressure to go this way, but it's not the policy yet.

Vote has passed, so now actual files are made, and are available at the same
location [1].

Vadim

[1] http://people.apache.org/~vgritsenko/regexp/

Vadim,

that is not the point. The procedure in itself is flawed. There might be
files now, but the procedure still has to be aligned to ASF wide guide
lines.

Before you wonder/think about conspiracy theories: Yes, I brought the
board (i.e. Henri) attention to this. It is necessary to change the
commons release procedures and if you think that experiences of other
PMCs (Velocity) don't count, let's try with a board opinion.

Best regards
Henning



Vadim Gritsenko schrieb:
> Henri Yandell wrote:
>> 3) Creating the actual files that are going to be released and voting
>> on them. There's pressure to go this way, but it's not the policy yet.
>
> Vote has passed, so now actual files are made, and are available at the
> same location [1].
>
> Vadim
>
> [1] http://people.apache.org/~vgritsenko/regexp/
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>

--
Henning P. Schmiedehausen -- hps [at] intermeta.de | J2EE, Linux
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine

"Save the cheerleader. Save the world."

Henning Schmiedehausen wrote:
> Vadim,
>
> that is not the point. The procedure in itself is flawed.

You missed it too :) Existing procedure might be flawed in somebody's opinion,
and I'm not arguing that it is ideal, but proposed procedure is even worse. It
makes any release impossible: release packages can be made available only after
the release itself is made. This makes me think that such procedure comes from
the camp not taking SCM seriously.

Since the objective of the change to the process is to verify steps done by RM,
the only viable procedure, in my view, is - (1) vote on SVN rev number (with
packages made available), (2) tagging and building a release, (3) quick vote on
resulting files. It's quick sine no actual software testing need to be
performed, just verify that zip unzips and tar untars.

Vadim

> There might be
> files now, but the procedure still has to be aligned to ASF wide guide
> lines.
>
> Before you wonder/think about conspiracy theories: Yes, I brought the
> board (i.e. Henri) attention to this. It is necessary to change the
> commons release procedures and if you think that experiences of other
> PMCs (Velocity) don't count, let's try with a board opinion.
>
> Best regards
> Henning
>
>
>
> Vadim Gritsenko schrieb:
>> Henri Yandell wrote:
>>> 3) Creating the actual files that are going to be released and voting
>>> on them. There's pressure to go this way, but it's not the policy yet.
>>
>> Vote has passed, so now actual files are made, and are available at
>> the same location [1].
>>
>> Vadim
>>
>> [1] http://people.apache.org/~vgritsenko/regexp/

Or even better, let everyone follow their own procedures while loosely
fitting into a less restrictive set of obvious guidelines wrt
licensing / distribution locations /etc - so the rest of us don't have
to be punished because one or two projects are having issues getting
releases out....

On 3/19/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
> Henning Schmiedehausen wrote:
> > Vadim,
> >
> > that is not the point. The procedure in itself is flawed.
>
> You missed it too :) Existing procedure might be flawed in somebody's opinion,
> and I'm not arguing that it is ideal, but proposed procedure is even worse. It
> makes any release impossible: release packages can be made available only after
> the release itself is made. This makes me think that such procedure comes from
> the camp not taking SCM seriously.
>
> Since the objective of the change to the process is to verify steps done by RM,
> the only viable procedure, in my view, is - (1) vote on SVN rev number (with
> packages made available), (2) tagging and building a release, (3) quick vote on
> resulting files. It's quick sine no actual software testing need to be
> performed, just verify that zip unzips and tar untars.
>
> Vadim
>
> > There might be
> > files now, but the procedure still has to be aligned to ASF wide guide
> > lines.
> >
> > Before you wonder/think about conspiracy theories: Yes, I brought the
> > board (i.e. Henri) attention to this. It is necessary to change the
> > commons release procedures and if you think that experiences of other
> > PMCs (Velocity) don't count, let's try with a board opinion.
> >
> > Best regards
> > Henning
> >
> >
> >
> > Vadim Gritsenko schrieb:
> >> Henri Yandell wrote:
> >>> 3) Creating the actual files that are going to be released and voting
> >>> on them. There's pressure to go this way, but it's not the policy yet.
> >>
> >> Vote has passed, so now actual files are made, and are available at
> >> the same location [1].
> >>
> >> Vadim
> >>
> >> [1] http://people.apache.org/~vgritsenko/regexp/
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>


--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

On 19/03/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
> Henning Schmiedehausen wrote:
> > Vadim,
> >
> > that is not the point. The procedure in itself is flawed.
>
> You missed it too :) Existing procedure might be flawed in somebody's opinion,
> and I'm not arguing that it is ideal, but proposed procedure is even worse. It
> makes any release impossible: release packages can be made available only after
> the release itself is made. This makes me think that such procedure comes from
> the camp not taking SCM seriously.
>
> Since the objective of the change to the process is to verify steps done by RM,
> the only viable procedure, in my view, is - (1) vote on SVN rev number (with
> packages made available), (2) tagging and building a release, (3) quick vote on
> resulting files. It's quick sine no actual software testing need to be
> performed, just verify that zip unzips and tar untars.

I think one also needs to check that:
* that the various signature files are present and correct
* the zips and tars contain the same files as each other
* the zips and tars and contained jars contain the required NOTICE and
LICENSE files
* the source archive includes all the required sources from SVN
* the bin archive includes all the required files (apart from any
documented dependencies)

I don't think these can be determined directly from the contents of an
SVN rev number, so need to be checked after a potential release has
been built.

==

As to release voting:

Surely the most important thing is to ensure that a build is not
released to the general public - i.e. not put in the dist tree -
before the vote has passed.

So long as the build files are in a private area - e.g. the RM's
public_html directory - (and maybe are named as pre-release) the vote
can be done on the actual files.

S///

sebb wrote:
> On 19/03/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
>> resulting files. It's quick sine no actual software testing need to be
>> performed, just verify that zip unzips and tar untars.
>
> I think one also needs to check that:
> * that the various signature files are present and correct
> * the zips and tars contain the same files as each other
> * the zips and tars and contained jars contain the required NOTICE and
> LICENSE files
> * the source archive includes all the required sources from SVN
> * the bin archive includes all the required files (apart from any
> documented dependencies)

(This is done by ant, btw, and so is 99% reproducible)

> I don't think these can be determined directly from the contents of an
> SVN rev number, so need to be checked after a potential release has
> been built.

Hence I mentioned 'quick check of release files'. Would satisfy even procedure
extremists.

> ==
>
> As to release voting:
>
> Surely the most important thing is to ensure that a build is not
> released to the general public - i.e. not put in the dist tree -
> before the vote has passed.
>
> So long as the build files are in a private area - e.g. the RM's
> public_html directory - (and maybe are named as pre-release) the vote
> can be done on the actual files.

Actual files, as you might have noticed, are impossible to produce before
release is tagged. To tag a release, a vote must pass. Best you could do is to
produce 'rc' build off of trunk.

Vadim

On 19/03/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
> sebb wrote:
> > On 19/03/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
> >> resulting files. It's quick sine no actual software testing need to be
> >> performed, just verify that zip unzips and tar untars.
> >
> > I think one also needs to check that:
> > * that the various signature files are present and correct
> > * the zips and tars contain the same files as each other
> > * the zips and tars and contained jars contain the required NOTICE and
> > LICENSE files
> > * the source archive includes all the required sources from SVN
> > * the bin archive includes all the required files (apart from any
> > documented dependencies)
>
> (This is done by ant, btw, and so is 99% reproducible)

It's the other 1% that is the problem ...

>
> > I don't think these can be determined directly from the contents of an
> > SVN rev number, so need to be checked after a potential release has
> > been built.
>
> Hence I mentioned 'quick check of release files'. Would satisfy even procedure
> extremists.
>
> > ==
> >
> > As to release voting:
> >
> > Surely the most important thing is to ensure that a build is not
> > released to the general public - i.e. not put in the dist tree -
> > before the vote has passed.
> >
> > So long as the build files are in a private area - e.g. the RM's
> > public_html directory - (and maybe are named as pre-release) the vote
> > can be done on the actual files.
>
> Actual files, as you might have noticed, are impossible to produce before
> release is tagged. To tag a release, a vote must pass. Best you could do is to
> produce 'rc' build off of trunk.

Surely voting on creating a tag (if this is necessary) is completely
different from voting on a release?

S

sebb wrote:
> Surely voting on creating a tag (if this is necessary)

Absolutely. Any release tag must be a community decision == vote is required.


> is completely different from voting on a release?

Not to me.

Voting on a release (on a tag) signifies that software is in a state where it
can be released to general public.

Voting on a files (produced from release tag) is a mechanical vote on
correctness of files produced by ant.

Vadim

On 19/03/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
> sebb wrote:
> > Surely voting on creating a tag (if this is necessary)
>
> Absolutely. Any release tag must be a community decision == vote is required.
>
>
> > is completely different from voting on a release?
>
> Not to me.
>
> Voting on a release (on a tag) signifies that software is in a state where it
> can be released to general public.
>
> Voting on a files (produced from release tag) is a mechanical vote on
> correctness of files produced by ant.
>

AFAIK, the ASF rules are that files must not be released to the
general public without a formal vote by the PMC on the release, which
I take to mean voting on the files which are proposed to be released.

Requiring consensus on tagging seems sensible, but I'm not sure it is required.

The problem here seems to be that it is not possible to use one vote
to do both; therefore it seems to me that the sensible thing to do is
to have two votes.

The first vote (on tagging) seems to me to be something that relates
mainly to committers working on the project.

The second vote has to involve PMC members; others can vote, but their
votes generally do not count (though I guess a -1 would need to be
investigated).

Seems to me that there needs to be formal documentation of the
required and recommended release processes.

S///

You have to be kidding me..

The only problem I see is that people are all caught up in policies /
processes but I've yet to hear what the actual root "problem" is. I'm
sure it's intended to somehow prevent something nasty that has
happened in the past but these policies don't have any logic that I'm
able to follow. Why does the ASF need to dictate how we vote on
releases?

Maybe I'm just having a bad morning, but for some reason this really
rubs me the wrong way and feels extremely inefficient.

On 3/19/07, sebb <sebbaz [at] gmail.com> wrote:
<snipped>
> The problem here seems to be that it is not possible to use one vote
> to do both; therefore it seems to me that the sensible thing to do is
> to have two votes.



--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

sebb wrote on Monday, March 19, 2007 3:09 PM:

> On 19/03/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
>> sebb wrote:
>>> Surely voting on creating a tag (if this is necessary)
>>
>> Absolutely. Any release tag must be a community decision =3D=3D vote =
is
>> required.
>>
>>
>>> is completely different from voting on a release?
>>
>> Not to me.
>>
>> Voting on a release (on a tag) signifies that software is in a state
>> where it can be released to general public.
>>
>> Voting on a files (produced from release tag) is a mechanical vote on
>> correctness of files produced by ant.
>>
>
> AFAIK, the ASF rules are that files must not be released to the
> general public without a formal vote by the PMC on the release, which
> I take to mean voting on the files which are proposed to be released.
>
> Requiring consensus on tagging seems sensible, but I'm not
> sure it is required.
>
> The problem here seems to be that it is not possible to use one vote
> to do both; therefore it seems to me that the sensible thing to do is
> to have two votes.
>
> The first vote (on tagging) seems to me to be something that relates
> mainly to committers working on the project.
>
> The second vote has to involve PMC members; others can vote, but their
> votes generally do not count (though I guess a -1 would need to be
> investigated).

And since no-one wants to vote twice, the vote is done on the released =
artifacts in the RM's private area (or a more official staging area). =
This includes also that the version is already tagged. If for whatever =
reason the vote does not pass we can drop the version from the SCM again =
.... since it did not represent a valid release anymore.

> Seems to me that there needs to be formal documentation of the
> required and recommended release processes.

- Jörg

BTW: I did not vote, exactly because I should have to check out from svn =
- and nobody can guarantee me that I have a proper environment to check =
the release I build myself.

On 19/03/07, Jesse Kuhnert <jkuhnert [at] gmail.com> wrote:
> You have to be kidding me..
>
> The only problem I see is that people are all caught up in policies /
> processes but I've yet to hear what the actual root "problem" is. I'm
> sure it's intended to somehow prevent something nasty that has
> happened in the past but these policies don't have any logic that I'm
> able to follow. Why does the ASF need to dictate how we vote on
> releases?

I don't have the references to hand, but I believe it is something to
do with providing some form of legal protection. There may be other
reasons as well.

> Maybe I'm just having a bad morning, but for some reason this really
> rubs me the wrong way and feels extremely inefficient.

As far as I know, only one formal vote is actually required by the
ASF; this must be by the PMC on the release itself.

> On 3/19/07, sebb <sebbaz [at] gmail.com> wrote:
> <snipped>
> > The problem here seems to be that it is not possible to use one vote
> > to do both; therefore it seems to me that the sensible thing to do is
> > to have two votes.
>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

I have a thought that may not be an immediate solution.

Isn't the correctness of a release from a build point of view a
testable condition? Shouldn't this be built in to the build system.

The apache servers would not allow an "invalid" package. They define
the pattern. Isn't this GUMP? Not knowing details but seeing emails.

Otherwise you are cloaking a software challenge within adminstratium
(http://en.wikipedia.org/wiki/Administratium)

(Sorry, if I'm a little incoherent, I'm finishing an ironman front to
back website release for work with last minute untested boss changes
and bug fixes in the fortran - model went from 1 to 5 modes .... )

Regards,
Dave Fisher

On Mar 19, 2007, at 9:55 AM, sebb wrote:

> On 19/03/07, Jesse Kuhnert <jkuhnert [at] gmail.com> wrote:
>> You have to be kidding me..
>>
>> The only problem I see is that people are all caught up in policies /
>> processes but I've yet to hear what the actual root "problem" is. I'm
>> sure it's intended to somehow prevent something nasty that has
>> happened in the past but these policies don't have any logic that I'm
>> able to follow. Why does the ASF need to dictate how we vote on
>> releases?
>
> I don't have the references to hand, but I believe it is something to
> do with providing some form of legal protection. There may be other
> reasons as well.
>
>> Maybe I'm just having a bad morning, but for some reason this really
>> rubs me the wrong way and feels extremely inefficient.
>
> As far as I know, only one formal vote is actually required by the
> ASF; this must be by the PMC on the release itself.
>
>> On 3/19/07, sebb <sebbaz [at] gmail.com> wrote:
>> <snipped>
>> > The problem here seems to be that it is not possible to use one
>> vote
>> > to do both; therefore it seems to me that the sensible thing to
>> do is
>> > to have two votes.
>>
>>
>>
>> --
>> Jesse Kuhnert
>> Tapestry/Dojo team member/developer
>>
>> Open source based consulting work centered around
>> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>>
>> ------------------------------------------------------------ ---------
>> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
>> For additional commands, e-mail: general-help [at] jakarta.apache.org
>>
>>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

"Jesse Kuhnert" <jkuhnert [at] gmail.com> writes:

> You have to be kidding me..
>
> The only problem I see is that people are all caught up in policies /
> processes but I've yet to hear what the actual root "problem" is. I'm
> sure it's intended to somehow prevent something nasty that has
> happened in the past but these policies don't have any logic that I'm
> able to follow. Why does the ASF need to dictate how we vote on
> releases?
>
> Maybe I'm just having a bad morning, but for some reason this really
> rubs me the wrong way and feels extremely inefficient.

The problem is that Vote-Then-Release leaves opportunities for the
small details to get missed and you end up with a sloppy release.
Examples include non-signed distributables, incomplete legal notices,
missing or incorrect hashes. The worst is someone slipping in some
malicious code in between the time the vote is cast and the release is
made.

When a PMC votes on a release they should be approving the exact bits
that hit the mirrors. That vote binds the ASF to be _legally_
responsible. The only way to have sufficient and appropriate
oversight is to give the PMC a chance to check that these final steps
of a release have been properly handled. Otherwise the PMC risks
releasing a half baked product.

It is completely appropriate for the ASF to set guidelines on release
procedures.

--
jaaron (who is not on the Jakarta PMC)

Sure, of course it's ok for the ASF to dictate policies - I just hope
it's ok for me to question them / point out their flaws.

So the real problem as far as I can tell is making sure a release is
legitimately licensed. There are other things like software quality,
but I guess it's assumed (by me at least) that we're all trying to
release as high a caliber of software as we are able given our
resources / time.

Somehow this still doesn't feel like a legitimate problem, or at least
it is not consistent with the rest of our daily practices. ..Like
committing a change to subversion. As far as I can tell there is no
legal difference between subversion repositories and released software
- is there? Isn't the end goal to prevent any naughty code coming out
of apache period? Non conforming code sitting in subversion would
appear to be just as guilty as anything else...So given your current
logic shouldn't we all be required to have a PMC vote for each commit
made into the repo?

It just feels like we're being treated a little bit like incompetents
in some way. Like maybe someone accidentally made a bad release once
or twice and so we must all suffer the same solution that they have.

Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
wanted to make sure I got my two cents in.

On 3/19/07, J Aaron Farr <farra [at] apache.org> wrote:
> "Jesse Kuhnert" <jkuhnert [at] gmail.com> writes:
>
> > You have to be kidding me..
> >
> > The only problem I see is that people are all caught up in policies /
> > processes but I've yet to hear what the actual root "problem" is. I'm
> > sure it's intended to somehow prevent something nasty that has
> > happened in the past but these policies don't have any logic that I'm
> > able to follow. Why does the ASF need to dictate how we vote on
> > releases?
> >
> > Maybe I'm just having a bad morning, but for some reason this really
> > rubs me the wrong way and feels extremely inefficient.
>
> The problem is that Vote-Then-Release leaves opportunities for the
> small details to get missed and you end up with a sloppy release.
> Examples include non-signed distributables, incomplete legal notices,
> missing or incorrect hashes. The worst is someone slipping in some
> malicious code in between the time the vote is cast and the release is
> made.
>
> When a PMC votes on a release they should be approving the exact bits
> that hit the mirrors. That vote binds the ASF to be _legally_
> responsible. The only way to have sufficient and appropriate
> oversight is to give the PMC a chance to check that these final steps
> of a release have been properly handled. Otherwise the PMC risks
> releasing a half baked product.
>
> It is completely appropriate for the ASF to set guidelines on release
> procedures.
>
> --
> jaaron (who is not on the Jakarta PMC)
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>


--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

------=_Part_46104_13732378.1174325935166
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think we have to remember that the ASF provides an important legal
umbrella here. By setting policies which we follow (which of course can be
debated), it prevents us from being sued if an SCO-type situation develops.
This would be a low-probability, but extremely catastrophic event,
especially since developers could be sued directly if they were operating
independently. The PMC plays an important role in shielding individual
developers from liability by approving releases according to defined
policies.

WILL





On 3/19/07, Jesse Kuhnert <jkuhnert [at] gmail.com> wrote:
>
> Sure, of course it's ok for the ASF to dictate policies - I just hope
> it's ok for me to question them / point out their flaws.
>
> So the real problem as far as I can tell is making sure a release is
> legitimately licensed. There are other things like software quality,
> but I guess it's assumed (by me at least) that we're all trying to
> release as high a caliber of software as we are able given our
> resources / time.
>
> Somehow this still doesn't feel like a legitimate problem, or at least
> it is not consistent with the rest of our daily practices. ..Like
> committing a change to subversion. As far as I can tell there is no
> legal difference between subversion repositories and released software
> - is there? Isn't the end goal to prevent any naughty code coming out
> of apache period? Non conforming code sitting in subversion would
> appear to be just as guilty as anything else...So given your current
> logic shouldn't we all be required to have a PMC vote for each commit
> made into the repo?
>
> It just feels like we're being treated a little bit like incompetents
> in some way. Like maybe someone accidentally made a bad release once
> or twice and so we must all suffer the same solution that they have.
>
> Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> wanted to make sure I got my two cents in.
>
> On 3/19/07, J Aaron Farr <farra [at] apache.org> wrote:
> > "Jesse Kuhnert" <jkuhnert [at] gmail.com> writes:
> >
> > > You have to be kidding me..
> > >
> > > The only problem I see is that people are all caught up in policies /
> > > processes but I've yet to hear what the actual root "problem" is. I'm
> > > sure it's intended to somehow prevent something nasty that has
> > > happened in the past but these policies don't have any logic that I'm
> > > able to follow. Why does the ASF need to dictate how we vote on
> > > releases?
> > >
> > > Maybe I'm just having a bad morning, but for some reason this really
> > > rubs me the wrong way and feels extremely inefficient.
> >
> > The problem is that Vote-Then-Release leaves opportunities for the
> > small details to get missed and you end up with a sloppy release.
> > Examples include non-signed distributables, incomplete legal notices,
> > missing or incorrect hashes. The worst is someone slipping in some
> > malicious code in between the time the vote is cast and the release is
> > made.
> >
> > When a PMC votes on a release they should be approving the exact bits
> > that hit the mirrors. That vote binds the ASF to be _legally_
> > responsible. The only way to have sufficient and appropriate
> > oversight is to give the PMC a chance to check that these final steps
> > of a release have been properly handled. Otherwise the PMC risks
> > releasing a half baked product.
> >
> > It is completely appropriate for the ASF to set guidelines on release
> > procedures.
> >
> > --
> > jaaron (who is not on the Jakarta PMC)
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> > For additional commands, e-mail: general-help [at] jakarta.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>


--
Forio Business Simulations

Will Glass-Husain
415 440-7500x89
wglass [at] forio.com
www.forio.com

------=_Part_46104_13732378.1174325935166--

>> You have to be kidding me..
>>
>> The only problem I see is that people are all caught up in policies /
>> processes but I've yet to hear what the actual root "problem" is. I'm
>> sure it's intended to somehow prevent something nasty that has
>> happened in the past but these policies don't have any logic that I'm
>> able to follow. Why does the ASF need to dictate how we vote on
>> releases?
>>
>> Maybe I'm just having a bad morning, but for some reason this really
>> rubs me the wrong way and feels extremely inefficient.
>
> The problem is that Vote-Then-Release leaves opportunities for the
> small details to get missed and you end up with a sloppy release.
> Examples include non-signed distributables, incomplete legal notices,
> missing or incorrect hashes. The worst is someone slipping in some
> malicious code in between the time the vote is cast and the release is
> made.

I may be wrong, but the ASF already has agreements with all
committers and PMCs.

So, anyone slipping in malicious code into a release has already
agreed not to do it. Anyone doing so is tagged.

This means that any of these mistakes are "bugs". And while we want
everything to be perfect, not everything is that way.

>
> When a PMC votes on a release they should be approving the exact bits
> that hit the mirrors. That vote binds the ASF to be _legally_
> responsible. The only way to have sufficient and appropriate
> oversight is to give the PMC a chance to check that these final steps
> of a release have been properly handled. Otherwise the PMC risks
> releasing a half baked product.

So each project requires 3 release managers? The vote to release
should appoint a release manager, and the manager should make the
release. Their word is their bond. Who wants the reputation as a
screw up? If the PMCs delegate it to another person then karma is
reflected.

>
> It is completely appropriate for the ASF to set guidelines on release
> procedures.

Appropriate as long as they don't treat contributers like children.
The ASF should have policies that enable open source, and not
discourage it.

If someone screws up too many releases then the community can take
away their karma.

The ASF should automate all those bit manipulations. Didn't someone
in this thread say that ant does 99% of it?

Regards,
Dave Fisher


>
> --
> jaaron (who is not on the Jakarta PMC)
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

Jesse Kuhnert wrote:
> Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> wanted to make sure I got my two cents in.

Make that two of us. ASF today indeed contains much more Administratium (thanks
Dave, great link!) than it used to.

Vadim

On Mon, 2007-03-19 at 13:30 -0400, Jesse Kuhnert wrote:
> Sure, of course it's ok for the ASF to dictate policies - I just hope
> it's ok for me to question them / point out their flaws.
>
> So the real problem as far as I can tell is making sure a release is
> legitimately licensed. There are other things like software quality,
> but I guess it's assumed (by me at least) that we're all trying to
> release as high a caliber of software as we are able given our
> resources / time.
>
> Somehow this still doesn't feel like a legitimate problem, or at least
> it is not consistent with the rest of our daily practices. ..Like
> committing a change to subversion. As far as I can tell there is no
> legal difference between subversion repositories and released software
> - is there? Isn't the end goal to prevent any naughty code coming out
> of apache period? Non conforming code sitting in subversion would
> appear to be just as guilty as anything else...So given your current
> logic shouldn't we all be required to have a PMC vote for each commit
> made into the repo?
>
> It just feels like we're being treated a little bit like incompetents
> in some way. Like maybe someone accidentally made a bad release once
> or twice and so we must all suffer the same solution that they have.
>
> Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> wanted to make sure I got my two cents in.
>

Jesse,

You are certainly not alone. I have always been of an option that the
content of the SVN repository is what truly represents the source code
of ASF software, with packaged releases merely being versioned snapshots
officially endorsed by the project committers and the respective PMC and
recommended for use by the end users. I am not a legal expect by any
stretch of imagination but I think ASF may be equally liable for any
given revision in its official SVN repository as for its packaged
releases.

In Commons HttpClient / HttpComponents land we historically voted on SVN
revisions and published release packages based on a lazy consensus if no
one raised complaints about the content of the release packages.

Oleg

> On 3/19/07, J Aaron Farr <farra [at] apache.org> wrote:
> > "Jesse Kuhnert" <jkuhnert [at] gmail.com> writes:
> >
> > > You have to be kidding me..
> > >
> > > The only problem I see is that people are all caught up in policies /
> > > processes but I've yet to hear what the actual root "problem" is. I'm
> > > sure it's intended to somehow prevent something nasty that has
> > > happened in the past but these policies don't have any logic that I'm
> > > able to follow. Why does the ASF need to dictate how we vote on
> > > releases?
> > >
> > > Maybe I'm just having a bad morning, but for some reason this really
> > > rubs me the wrong way and feels extremely inefficient.
> >
> > The problem is that Vote-Then-Release leaves opportunities for the
> > small details to get missed and you end up with a sloppy release.
> > Examples include non-signed distributables, incomplete legal notices,
> > missing or incorrect hashes. The worst is someone slipping in some
> > malicious code in between the time the vote is cast and the release is
> > made.
> >
> > When a PMC votes on a release they should be approving the exact bits
> > that hit the mirrors. That vote binds the ASF to be _legally_
> > responsible. The only way to have sufficient and appropriate
> > oversight is to give the PMC a chance to check that these final steps
> > of a release have been properly handled. Otherwise the PMC risks
> > releasing a half baked product.
> >
> > It is completely appropriate for the ASF to set guidelines on release
> > procedures.
> >
> > --
> > jaaron (who is not on the Jakarta PMC)
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> > For additional commands, e-mail: general-help [at] jakarta.apache.org
> >
> >
>
>

On 3/19/07, Oleg Kalnichevski <olegk [at] apache.org> wrote:
> On Mon, 2007-03-19 at 13:30 -0400, Jesse Kuhnert wrote:
> > Sure, of course it's ok for the ASF to dictate policies - I just hope
> > it's ok for me to question them / point out their flaws.
> >
> > So the real problem as far as I can tell is making sure a release is
> > legitimately licensed. There are other things like software quality,
> > but I guess it's assumed (by me at least) that we're all trying to
> > release as high a caliber of software as we are able given our
> > resources / time.
> >
> > Somehow this still doesn't feel like a legitimate problem, or at least
> > it is not consistent with the rest of our daily practices. ..Like
> > committing a change to subversion. As far as I can tell there is no
> > legal difference between subversion repositories and released software
> > - is there? Isn't the end goal to prevent any naughty code coming out
> > of apache period? Non conforming code sitting in subversion would
> > appear to be just as guilty as anything else...So given your current
> > logic shouldn't we all be required to have a PMC vote for each commit
> > made into the repo?
> >
> > It just feels like we're being treated a little bit like incompetents
> > in some way. Like maybe someone accidentally made a bad release once
> > or twice and so we must all suffer the same solution that they have.
> >
> > Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> > wanted to make sure I got my two cents in.
> >
>
> Jesse,
>
> You are certainly not alone. I have always been of an option that the
> content of the SVN repository is what truly represents the source code
> of ASF software, with packaged releases merely being versioned snapshots
> officially endorsed by the project committers and the respective PMC and
> recommended for use by the end users. I am not a legal expect by any
> stretch of imagination but I think ASF may be equally liable for any
> given revision in its official SVN repository as for its packaged
> releases.

sure. and the SVN repo has protections that releases do not: commits
are sent to a mailing list for oversight and archival. they are kept
in a central place that is easy to control and not distributed
widely. the consequences for problems are small and easily remedied.

the actual bits that are distributed as an officially endorsed release
do not have the luxury of diffs sent to the development lists, nor are
they easily controlled from a central location. the releases are
extensively mirrored by servers all over the place. releases are nigh
impossible to recall. thus, with the broader audience, the
consequences for problems are greatly magnified and are not easily
remedied.

i can understand complaints about the process, but let's not pretend
that releases do not need an extra measure of protection that the
repositories do not.

that said, i would love to see some more automation of
signature/hash/LICENSE/NOTICE/zip-tar-consistency checking. i believe
Henk Penning does have some automated signature checking set up, but
that's all i know of, and it only happens after the release is out.

anyone frustrated with the process is quite welcome to step up and
hack up something to ease the frustration. :)

> In Commons HttpClient / HttpComponents land we historically voted on SVN
> revisions and published release packages based on a lazy consensus if no
> one raised complaints about the content of the release packages.
>
> Oleg
>
> > On 3/19/07, J Aaron Farr <farra [at] apache.org> wrote:
> > > "Jesse Kuhnert" <jkuhnert [at] gmail.com> writes:
> > >
> > > > You have to be kidding me..
> > > >
> > > > The only problem I see is that people are all caught up in policies /
> > > > processes but I've yet to hear what the actual root "problem" is. I'm
> > > > sure it's intended to somehow prevent something nasty that has
> > > > happened in the past but these policies don't have any logic that I'm
> > > > able to follow. Why does the ASF need to dictate how we vote on
> > > > releases?
> > > >
> > > > Maybe I'm just having a bad morning, but for some reason this really
> > > > rubs me the wrong way and feels extremely inefficient.
> > >
> > > The problem is that Vote-Then-Release leaves opportunities for the
> > > small details to get missed and you end up with a sloppy release.
> > > Examples include non-signed distributables, incomplete legal notices,
> > > missing or incorrect hashes. The worst is someone slipping in some
> > > malicious code in between the time the vote is cast and the release is
> > > made.
> > >
> > > When a PMC votes on a release they should be approving the exact bits
> > > that hit the mirrors. That vote binds the ASF to be _legally_
> > > responsible. The only way to have sufficient and appropriate
> > > oversight is to give the PMC a chance to check that these final steps
> > > of a release have been properly handled. Otherwise the PMC risks
> > > releasing a half baked product.
> > >
> > > It is completely appropriate for the ASF to set guidelines on release
> > > procedures.
> > >
> > > --
> > > jaaron (who is not on the Jakarta PMC)
> > >
> > > ------------------------------------------------------------ ---------
> > > To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> > > For additional commands, e-mail: general-help [at] jakarta.apache.org
> > >
> > >
> >
> >
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

"Nathan Bubna" <nbubna [at] gmail.com> writes:

> that said, i would love to see some more automation of
> signature/hash/LICENSE/NOTICE/zip-tar-consistency checking. i believe
> Henk Penning does have some automated signature checking set up, but
> that's all i know of, and it only happens after the release is out.
>
> anyone frustrated with the process is quite welcome to step up and
> hack up something to ease the frustration. :)

ARAT helps:

http://code.google.com/p/arat/

And again you can code up a lot of this in Ant or use some of Maven's plugins.

--
jaaron

Ok so I'm a liar...I did want to point out that from my experience
even the most formal voting process won't get the desired results -
that everyone on the project certifies and checks that the binaries
going out are good. More than likely 90% of the time everyone just
votes yes or no and trusts that the person managing the release knows
what they are doing. .....but these are small points. Still, they do
point to the voting process being meaningless other than all of the
PMC's putting their names on it if it should go poorly. (though in a
true team sort of mindset you'd think that this would always be the
case with / without votes / other processes...)

Automation is good. Esp. if it lets us opt to always trust committer X
managing a release once and let a diligent little script do everything
else for else without any intervention. That would be great and would
bring me back to where I already was. ;)

On 3/19/07, Nathan Bubna <nbubna [at] gmail.com> wrote:
<snipped>
> the actual bits that are distributed as an officially endorsed release
> do not have the luxury of diffs sent to the development lists, nor are
> they easily controlled from a central location. the releases are
> extensively mirrored by servers all over the place. releases are nigh
> impossible to recall. thus, with the broader audience, the
> consequences for problems are greatly magnified and are not easily
> remedied.
<snipped>


--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

On 3/19/07, Jesse Kuhnert <jkuhnert [at] gmail.com> wrote:
> Ok so I'm a liar...I did want to point out that from my experience
> even the most formal voting process won't get the desired results -
> that everyone on the project certifies and checks that the binaries
> going out are good. More than likely 90% of the time everyone just
> votes yes or no and trusts that the person managing the release knows
> what they are doing. .....but these are small points.

ah, you say the glass is 90% empty, others might say it is 10% full.
:) at least, release-then-vote provides the opportunity for oversight
of the actual binaries to be released.

> Still, they do
> point to the voting process being meaningless other than all of the
> PMC's putting their names on it if it should go poorly. (though in a
> true team sort of mindset you'd think that this would always be the
> case with / without votes / other processes...)

meaning can be quite relative. as this process is in large part due
to legal, "CYA" necessities, "meaningless" things such as the mere
opportunity for oversight of those bits and any actual (and perhaps
even perceived) PMC oversight are important to the foundation. our
best bet here is to automate the oversight as much as possible to ease
the burden of the process. i will definitely be giving this ARAT tool
a look.

> Automation is good. Esp. if it lets us opt to always trust committer X
> managing a release once and let a diligent little script do everything
> else for else without any intervention. That would be great and would
> bring me back to where I already was. ;)
>
> On 3/19/07, Nathan Bubna <nbubna [at] gmail.com> wrote:
> <snipped>
> > the actual bits that are distributed as an officially endorsed release
> > do not have the luxury of diffs sent to the development lists, nor are
> > they easily controlled from a central location. the releases are
> > extensively mirrored by servers all over the place. releases are nigh
> > impossible to recall. thus, with the broader audience, the
> > consequences for problems are greatly magnified and are not easily
> > remedied.
> <snipped>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

On 3/19/07, Jesse Kuhnert <jkuhnert [at] gmail.com> wrote:
> Sure, of course it's ok for the ASF to dictate policies - I just hope
> it's ok for me to question them / point out their flaws.
>
> So the real problem as far as I can tell is making sure a release is
> legitimately licensed. There are other things like software quality,
> but I guess it's assumed (by me at least) that we're all trying to
> release as high a caliber of software as we are able given our
> resources / time.
>
> Somehow this still doesn't feel like a legitimate problem, or at least
> it is not consistent with the rest of our daily practices. ..Like
> committing a change to subversion. As far as I can tell there is no
> legal difference between subversion repositories and released software
> - is there? Isn't the end goal to prevent any naughty code coming out
> of apache period? Non conforming code sitting in subversion would
> appear to be just as guilty as anything else...So given your current
> logic shouldn't we all be required to have a PMC vote for each commit
> made into the repo?
>
> It just feels like we're being treated a little bit like incompetents
> in some way. Like maybe someone accidentally made a bad release once
> or twice and so we must all suffer the same solution that they have.

There are all sorts of things that can go wrong when cutting a release
- an example the other day - Tomcat 5.5.23 had/has a problem because
the RM didn't have a jar in his local environment - its not a
guarantee I know (Tomcat produce artifacts to vote on before release!)
- but the more pairs of eyes checking out the distro before it goes
out has got to be a good thing. Its not about incompetance, just
catching mistakes before rather than after. I also don't get your
"suffering" point - most projects can produce a RC quickly - Tag &
Build - doesn't take long - so where is the suffering in doing that
before calling a vote?

Niall

> Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> wanted to make sure I got my two cents in.
>
> On 3/19/07, J Aaron Farr <farra [at] apache.org> wrote:
> > "Jesse Kuhnert" <jkuhnert [at] gmail.com> writes:
> >
> > > You have to be kidding me..
> > >
> > > The only problem I see is that people are all caught up in policies /
> > > processes but I've yet to hear what the actual root "problem" is. I'm
> > > sure it's intended to somehow prevent something nasty that has
> > > happened in the past but these policies don't have any logic that I'm
> > > able to follow. Why does the ASF need to dictate how we vote on
> > > releases?
> > >
> > > Maybe I'm just having a bad morning, but for some reason this really
> > > rubs me the wrong way and feels extremely inefficient.
> >
> > The problem is that Vote-Then-Release leaves opportunities for the
> > small details to get missed and you end up with a sloppy release.
> > Examples include non-signed distributables, incomplete legal notices,
> > missing or incorrect hashes. The worst is someone slipping in some
> > malicious code in between the time the vote is cast and the release is
> > made.
> >
> > When a PMC votes on a release they should be approving the exact bits
> > that hit the mirrors. That vote binds the ASF to be _legally_
> > responsible. The only way to have sufficient and appropriate
> > oversight is to give the PMC a chance to check that these final steps
> > of a release have been properly handled. Otherwise the PMC risks
> > releasing a half baked product.
> >
> > It is completely appropriate for the ASF to set guidelines on release
> > procedures.
> >
> > --
> > jaaron (who is not on the Jakarta PMC)

Something being a good idea and being "required ASF policy" are really
very different things.

The suffering is in the implication that I'm not already being
careful. That we're not all supposed to be slightly better than
average developers with the apache branding and all. The fact that
it's ok to send me emails telling me I'm part of a "problem project"
because I haven't followed some new guidelines put in place because of
other peoples mistakes - mistakes I haven't even made ....is really
just insulting and annoying.

I wonder how often these kinds of emails come out on the google code
or sourceforge lists? :/

On 3/19/07, Niall Pemberton <niall.pemberton [at] gmail.com> wrote:
<snipped>
> There are all sorts of things that can go wrong when cutting a release
> - an example the other day - Tomcat 5.5.23 had/has a problem because
> the RM didn't have a jar in his local environment - its not a
> guarantee I know (Tomcat produce artifacts to vote on before release!)
> - but the more pairs of eyes checking out the distro before it goes
> out has got to be a good thing. Its not about incompetance, just
> catching mistakes before rather than after. I also don't get your
> "suffering" point - most projects can produce a RC quickly - Tag &
> Build - doesn't take long - so where is the suffering in doing that
> before calling a vote?
>
> Niall



--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

------=_Part_135296_31663500.1174336851729
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/19/07, Jesse Kuhnert <jkuhnert [at] gmail.com> wrote:
>
> Something being a good idea and being "required ASF policy" are really
> very different things.
>
> The suffering is in the implication that I'm not already being
> careful.


So you've never made a mistake in your life? And you're willing to bet a law
suit on continuing to never make a mistake?

That we're not all supposed to be slightly better than
> average developers with the apache branding and all. The fact that
> it's ok to send me emails telling me I'm part of a "problem project"
> because I haven't followed some new guidelines put in place because of
> other peoples mistakes - mistakes I haven't even made ....is really
> just insulting and annoying.
>
> I wonder how often these kinds of emails come out on the google code
> or sourceforge lists? :/


Those sites provide infrastructure, but absolutely no legal protection.

--
Martin Cooper


On 3/19/07, Niall Pemberton <niall.pemberton [at] gmail.com> wrote:
> <snipped>
> > There are all sorts of things that can go wrong when cutting a release
> > - an example the other day - Tomcat 5.5.23 had/has a problem because
> > the RM didn't have a jar in his local environment - its not a
> > guarantee I know (Tomcat produce artifacts to vote on before release!)
> > - but the more pairs of eyes checking out the distro before it goes
> > out has got to be a good thing. Its not about incompetance, just
> > catching mistakes before rather than after. I also don't get your
> > "suffering" point - most projects can produce a RC quickly - Tag &
> > Build - doesn't take long - so where is the suffering in doing that
> > before calling a vote?
> >
> > Niall
>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

------=_Part_135296_31663500.1174336851729--

Martin Cooper wrote:
> Those sites provide infrastructure, but absolutely no legal protection.

Who says there is no way to combine legal protection and non-absurd procedures?
For example: community votes for a release, RM tags a release (and prepares
files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition
change process), done.

And the big one. The main goal ASF exists for is fostering software development
communities. With second goal being software released in the process. And the
legal part here is an *evil necessity*, it is *not* a goal.

Vadim

------=_Part_135937_21201102.1174339207016
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/19/07, Vadim Gritsenko <vadim [at] reverycodes.com> wrote:
>
> Martin Cooper wrote:
> > Those sites provide infrastructure, but absolutely no legal protection.
>
> Who says there is no way to combine legal protection and non-absurd
> procedures?


Not me. We don't have absurd procedures, so we're already there.

For example: community votes for a release, RM tags a release (and prepares
> files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC
> composition
> change process), done.


PMCs are not about rubber-stamping anything. They are about project
oversight and responsibility.

And the big one. The main goal ASF exists for is fostering software
> development
> communities. With second goal being software released in the process. And
> the
> legal part here is an *evil necessity*, it is *not* a goal.


Interesting perspective. But my reading of the first couple of sentences of
this page suggests otherwise:

http://www.apache.org/foundation/

--
Martin Cooper


Vadim
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

------=_Part_135937_21201102.1174339207016--